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Svsteme d'acces a un reseau adapte pour la mise en oeuvre d'un procede 
a signature simplifiee, et serveur pour sa realisation, 

Uinvention concerne un systeme d'acces ^ un reseau adapte pour la 
5 mise en oeuvre d'un procede a signature simplifiee, et un sen/eur pour sa 
realisation. 

Plus precisement, invention concerne un systeme comportant : 

- au moins un poste d'utilisateur equipe d'un navigateur internet, 

- un serveur proxy par leque! passent tous les flux d'informations 
10 echang^s entre le ou chaque poste d'utiltsateur et ledit reseau, 

- plusieurs fournisseurs de services raccord^s audit rSseau, 
chaque fournisseur de services etant apte ^ 6mettre une requSte 
d'authentification vers le poste de I'utilisateur qui le contacte pour identifier et/ou 
authentlfier cet utilisateur avant de lui foumir des services personnalises et/ou 

IS s^curises, la r§ponse ^ fournir par un meme utilisateur ^ cette requ§te 
d'authentification pouvant etre differente en fonction du foumisseur de services 
contacte, 

- au moins un serveur d'authentification propre a memoriser au 
moins une information d'authentlficatlon pour chaque utilisateur et a transmettre 

20 en rSponse a une requete d'authentification une reponse d'authentification 
contenant une information d'authentificatlon fonction a la fois du fournisseur de 
services ayant emis la requete d'authentification, et de {'identity de I'utilisateur 
ayant contacte ce foumisseur de services, et 

- un module a signature simplifiee apte a traitor automatiquement 
25 en lieu et place du ou de chaque poste d'utilisateur ies requites 

d'authentification emises par les fournisseurs de services oontact^s, ce module 
6tant apte pour chaque utilisateur : 

- a dinger les requetes d'authentification vers le serveur 
d'autinentification approprie, et 
30 - ^ retransmettre au foumisseur de services la reponse 

d'authentification correspondante transmise par le serveur d'authentification 
approprie. 
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Ces syst^mes permettent de mettre en ceuvre un proc6de ^ 
signature simpiifi§e plus connu sous les termes de proc6d§ SSO ("Single Sign 
On" ou "Simplified Sign On"). Des renseignements plus precis sur un exemple 
de proc6d§ SSO peuvent §tre obtenus § la lecture des recommandations 

5 d§finles par le consortium d'entreprises appel§ Liberty Alliance, dont le but est 
le developpement des transactions sur Internet. Ces recommandations peuvent 
par exemple, §tre obtenues ^ partir du site Internet http://w\ww.projectliberty.org. 

Les proced§s SSO visent a simplifier Tidentification et/ou 
I'autlientification d'un utilisateur sur la toile d'araign6e mondiale plus connue 

10 sous les termes de WEB (World Wide Web). Dans la suite de cette description, 
la toile d'araignee mondiale sera simplement d6sign§e par le terme reseau 
internet. 

Les proc§d6s SSO et notamment ceux conformes aux 
recommandations de Liberty Alliance, implSmentent le module ^ signature 

15 simpllfi§e dans le serveur proxy. Toutefois, cette solution presente 
rinconv6nient qu'elle implique des modifications substantielles des serveurs 
proxy existants et qu'elle suppose une augmentation des traitements ^ r^aliser 
par les serveurs proxy existants. 

L'invention vise a rem§dier a cet inconvenient en proposant un 

20 syst^me d'accds d un reseau ^ commutation de paquets adapte pour la mise 
en oeuvre d'un precede SSO dans lequel les modifications a apporter au 
serveur proxy sont mineures et les consequences sur la charge d traiter sent 
mineures. 

L'invention a done pour objet un syst^me tel que d^crit ci-dessus, 
25 caract6ris§ en ce qu'il comporte uri serveur suppl^mentaire ind6pendant du 
serveur proxy, le module d signature simprrfi^e 6tant impl6ment6 dans ce 
serveur suppl6mentaire, et en ce que le serveur proxy est Equips d'une 
interface pemnettant de raccorder le serveur supplSmentaire et de transmettre 
au moins les requ§tes d'authentification emises par les fournisseurs de services 
30 contactes audit serveur supplementaire pour traitement de ces requites par le 
module a signature simplifiee. 

Suivant d'autres caracteristiques du systeme confomne a l'invention, 
celui-ci se caracterise en ce que : 
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- le module d signature simplifi^e comporte un sous-module propre ^ 
identifier i'utilisateur a partir de son adresse reseau et ^ ajouter un identificateur 
de I'utilisateur aux requetes d'authentification dirigees vers les serveurs 
d'authentification ; 

5 - ladite au moins une information d'authentification memoris6e pour 

chaque utilisateur comprend une information sur un niveau d'authentification 
disponible pour cet utilisateur, en ce que chaque requete d'authentification 
emise par un fournisseur de services specifie des caracteristiques sur le niveau 
d*authentification requis par ce fournisseur de services pour pouvoir acceder 

10 aux services qu'il propose, en ce que le ou chaque serveur d'authentification est 
apte a comparer les caracteristiques sur le niveau d'authentification requis 
sp§cifi6 par la requete d'authentification a rinformation sur le niveau 
d'authentification disponible, de mani^re a determiner si le niveau 
d'authentification requis correspond au niveau d'authentification disponible pour 

15 cet utilisateur, et en ce que te ou chaque serveur d'authentification est apte a 
emettre vers I'utilisateur une requ§te d'authentification active propre a activer 
sur le poste de I'utilisateur un processus interactif d'identification et/ou 
d'authentification de I'utilisateur si le niveau d'authentification requis ne 
correspond pas au niveau d'authentification disponible ; 

20 - le serveur supplementaire comporte un sous-module propre a 

diriger la reponse de Tutilisateur aux requetes d'authentification active vers le 
serveur d'authentification qui I'a emise ; 

- le serveur supplementaire comporte un sous module propre d 
diriger la requete d'authentification active vers le poste de I'utilisateur ; 

25 - ie module S signature simplifiee comporte un sous-module capable 

d'ajouter aux requStes transmises par le poste d'utilisateur vers un fournisseur 
de services un signal d'identification de service a signature simplifi6e en 
reponse auquel le fournisseur de services dmet la requSte d'authentification ; 

- le serveur suppldmentaire et le serveur proxy sont aptes a 
30 communiquer I'un avec I'autre en mettant en CBuvre un protocole de transfert de 

flux HTTP (Hyper Text Transfer Protocol) ; 
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- le protocole de transfert de flux HTTP est le protocole iCAP 
(Internet Content Adaptation Protocol) ou le protocole OCP (OPES Call Out 
Protocol). 

- le serveur supplSmentaire est uniquement apte d communiquer 
5 avec les fournisseurs de services par rintermediaire du protocole de transfert 

de flux HTTP mis en oeuvre entre lui et le serveur proxy ; 

- le serveur supplementaire implemente egalement un serveur et/ou 
un client HTTP (Hyper Text Transfer Protocol) pour communiquer directement 
avec le ou chaque fournisseur de services et/ou le ou chaque serveur 

10 d'authentification uniquement a Talde du protocole HTTP ; 

- il comporte un fournisseur d'acces audit reseau auquel doit se 
connecter le ou chaque poste d'utilisateur pour pouvoir acceder audit reseau, 
ce fournisseur d'acces etant 6quip§ du serveur proxy ; 

- ledit r6seau est la telle d'aralgnee mondiale. 

15 L'invention sera mieux comprise a la lecture de la description qui va 

suivre donnee uniquement a titre d'exemple et feite en se ref§rant aux dessins 
sur iesquels : 

- la figure 1 est une illustration sch6matique de Tarchitecture d'un 
systeme conforme a l'invention, 

20 - la figure 2 est un organigramme d'un precede a signature simplifiee 

mis en oeuvre dans le systeme de la figure 1, et 

- les figures 3 et 4 sont des illustrations schematiques de la 
circulation des flux d'infomiations entre les differents equipements du systeme 
de la figure 1 . 

25 La figure 1 represente un systeme, designe par ia reference generate 

2, d*acces a un reseau 4 d commutation de paquets adapte pour la mise en 
oeuvre d'un proced§ SSO conforme aux recommendations d§finies par Liberty 
Alliance. 

Les recommandations 6tablies par Liberty Alliance definissent 
30 Torganisation et les fonctionnalftes des diff6rents equipements ou groupes 
d'equipements du systeme 2 avec une precision sufTisante pour que I'homme 
du metier a la lecture de ces recommandations puisse fabrlquer ses 
equipements. Ces recommandations ne decrivent pas la realisation detalllee de 



wo 2005/034468 



5 



PCT/FR2004/002272 



chacun de ces ^quipements. Par consequent, dans ia suite de la description, on 
ne decrira de fa^on dStaill^e que le bloc d'equipement represents par un 
rectangle en pointille sur ia figure 1 , les autres Squipements du systeme 2 Stant 
realises de fagon conventionnelle § partir des recommandations de Liberty 
S Alliance. 

Le systeme 2 sera ici dScrit dans le cas partlcuiier oil le rdseau 4 est 
le reseau internet. 

Le systeme 2 comporte de nombreux postes d'utilisateurs ayant des 
fonctionnalites similaires les unes aux autres ainsi que plusieurs fournisseurs 
10 d'acces internet, ayant egalement des fonctionnalites similaires les unes aux 
autres. Ici pour simplifier Tillustration de la figure 1, seul un poste d'utilisateur 10 
et un fournisseur d*acc§s 12 ont ete representes. 

Le poste 10 est apte a naviguer sur le reseau 4. A cet effet, il est 
forme, par exemple, d'un ordinateur conventlonnel 14 6quip6 d'un Scran et d'un 
IS clavier ainsi que d'un navigateur internet 16 plus connu sous le terme anglais 
de "browser". 

Le systeme 2 comporte 6galement de nombreux syst6mes 
fournisseurs de services ainsi que plusieurs serveurs d*authentification. Ici, 
seuls deux systemes fournisseurs de services 20, 22, designes fournisseurs, 
20 ainsi que deux serveurs d'authentiflcation 24, 26 sont representes sur ia figure 
1 pour simplifier Tillustration, 

Les fournisseurs de services 20, 22 sont destines a rend re des 
services a Tutilisateur du poste 10. 

Par exemple, ici, le fournisseur 20 est un serveur informatique propre 
25 d etablir des fiches de paye en fonction des informations qui lui sont 
communiquees par Tutilisateur du poste 10. Pour cela, le serveur 20 comporte 
un module 32 propre S identifier et d authent'rfier I'utilisateur du poste 10 de 
maniere d personnaliser et a s^curiser ie service qu'il rend a cet utilisateur. Plus 
pr^cisement, le fournisseur 20 est associS k une memoire 30 dans iaquelle est 
30 enregistree une liste 34 de serveurs d'authentiflcation connus du fournisseur 20 
ainsi qu'un niveau 36 d'authentification requis par ce fournisseur. 

La liste 34 comporte des identificateurs des serveurs 
d'authentification contenant des informations d'authenfrfication propres a 
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identifier et authentifier un utiiisateur aupr6s de ce foumlsseur de services. Une 
telle information est, par exemple, un niveau d'authentification disponible 
actuellement pour un utiiisateur donne. 

Le niveau d*authentification enregistr^ dans la m^moire 30 definit la 
5 qualite de rauthentification requise par le foumisseur 20. Dans le s/steme 2, a 
titre d'exemple, chaque niveau d'authentification peut prendre Tune quelconque 
des valeurs entieres comprises entre "1" et "5". Plus la valeur du niveau 
• d'authentification est petite, plus la qualite de rauthentification est faible. Ici, a 
titre d'exemple, le niveau d'authentification 36 est egal a "2". 
10 Les fonctions realisees par le module 32 sont decrites plus en detail 

en regard des figures 3 et 4 et rint6r§t de la liste 34 ainsi que du niveau 
d'authentification apparaTtra a la lecture de la suite de cette description. On 
mentionnera ici simplement le fait que le module 32 est capable d'emettre une 
requ§te d'authentification HTTP incluse dans une reponse HTTP pour 
15 authentifier Tutilisateur vers le poste 10 de cet utiiisateur. 

Le fournisseur 22 permet, par exemple, d Tutilisateur du poste 10 de 
gerer a distance ses comptes bancaires et d'effectuer Sgalement des 
transactions bancaires. Le fournisseur 22 comporte les m§mes elements que 
ceux decrlts en regard du fournisseur 20 a I'exception du fait que le niveau 
20 d'authentification 36 est remplace par un niveau d'authentification 38 egal a "4". 

Les serveurs d'authentification 24 et 26 sont destines a re pond re aux 
requetes d'authentification emises par les fournisseurs de services. A cet effet, 
les sen/eurs 24 et 26 sont associes chacun a une memoire 40, 41 dans laquelle 
est enregistree pour chaque utiiisateur connu de ce sen/eur, une information 
25 42, 43 d'authentification. Chaque infonnation d'authentification contient le 
niveau d'authentification disponible pour I'utllisateur correspondant. 

Chaque serveur d'authentification 24, 26 comporte egalement un 
module 44 de contrdle d'acces. Ce module permet aux serveurs 24 et 26 
d'Smettre une requdte d'authentification active de maniere a interroger 
30 Tufilisateur du poste 10 pour que celui-ci fournisse un jeu d'informations 
permettant de Tidentifier et de Tauthentifier avec un niveau d'authentification 
souhafte. Un jeu d'informations est, par exemple, un identificateur de I'utilisateur 
et son mot de passe. 
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Ces serveurs d'authentification sont connus sous les termes anglais 
"Identity provider". 

Le fournisseur d'acx)§s 12 est capable de remplir les fonctions 
classiques d'un fournisseur d'acces internet, c'est-S-dire notamment d'affecter 
S une adresse reseau au poste 10 pour que celui-ci puisse naviguer sur le r^seau 
4. 

A cat effet, il comporte un serveur proxy HTTP (Hyper Text Transfer 
Protocol) et un serveur 52 de controle d'acces. Le protocole HTTP existent est 
un protocole de communication utilise pour les echanges de donnees entre des 

10 clients HTTP et des serveurs HTTP connus sous les termes de serveur web. Le 
serveur proxy est place en coupure de flux entre le poste 10 et le reseau 4, 
c'est-a-dire que Tensemble des flux d'informations echanges entre le navigateur 
16 du poste 10 et le reseau 4 passe par Tintermediaire du serveur prox/ 50. 
AinsI, le serveur proxy 50 voit passer Tensemble des requetes et des r6ponses 

15 HTTP 6mises par le poste 10 ou vers le poste 10. 

Le serveur de controle d'acces 52 est capable d*identifier et 
d'authentifier Tutilisateur du poste 10 avant d'autoriser ce poste 10 si se 
connecter au reseau 4 et a naviguer sur celui-ci. Typiquement, I'utilisateu r du 
poste 10 s'identifie aupres du serveur 52 en fournissant un jeu d'informations 

20 contenant un identificateur connu sous le terme anglais de "login" et un mot de 
passe. Si Tutilisateur est correctement identifie et authentifie, c'est-a-dire que le 
jeu informations qu'il a fourni correspond a un abonnement valide aupres de ce 
fournisseur d'acces, le serveur 52 affecte a cet utilisateur une adresse reseau, 
c'est-a-dire ici une adresse IP (internet Protocol) pour naviguer sur le reseau 4. 

25 Dans le cas contraire, le serveur 52 interdit toute connexion au reseau 4. 

Le serveur 52 est egalement capable d'enregistrer dans une 
m^moire 54 d laquelle il est associd une liste 56 contenant pour chaque 
adresse IP affectee d un utilisateur, I'identificateur de I'utilisateur correspond ant. 
Cette liste est mise d jour automatiquement par le serveur 52. 

30 Le fournisseur d'acces 12 comporte un serveur iCAP 60 (Internet 

Content Adaptation Protocol) plac§ a c6t6 du serveur 50 et raccord6 a celui-ci 
par rintemiediaire d'une liaison filaire 62 ou d'un reseau local. Le protocole 
iCAP existent est normalise par Torganisme IETF (Internet Engineering Task 
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Force) pour la transformation systematique de contenus sur Internet. Ainsi, ie 
serveur 60 et Ie serveur 50 sont capables de communiquer Tun avec Tautre en 
mettant en oeuvre le protocole iCAP. Plus pr§cisement, Ie serveur 50 est apte ^ 
communiquer au serveur 60 des requStes ou des reponses HTTP pr6sentes 
5 dans les flux d'informations ^changes entre le poste 10 et le r§seau 4 et Ie 
sen/eur 60 est §galement capable de transmettre des requ§tes ou des 
reponses HTTP apres les avoir modifiees au serveur 50. 

De maniere a impl6menter un client iCAP dans le serveur proxy 50 
celui-ci est equipe d'une interface iCAP 64 comportant un connecteur 
10 permettant de le raccorder au serveur 60. 

^interface 64 est ici configurSe pour transmettre au serveur 60 
uniquement les requites ou les reponses HTTP qui doivent etre modifiees pour 
la mise en ceuvre du proc§d6 SSO. 

Le serveur 60 est 6quip6 d'un module SSO 66 propre a prendre en 
15 charge tous les traitements specifiques requis par la mise en oeuvre du procede 
SSO. Ce module 66 comporte trois sous-modules 68, 70 et 72 conrespondant 
chacun a un service iCAP. Ces sous-modules seront decrits plus en detail en 
regard de chacune des figures 3 et 4. 

Le serveur 60 est associe a la m6moire 54 qui contient egalement 
20 una liste 76 des serveurs d'authentification connus par chaque utilisateur. Cette 
liste 76 regroupe pour chaque utilisateur, les identrficateurs des differents 
sen/eurs d'authentification dans lesquels sont memorisees des informations 
d'authentlfication pour cet utilisateur. 

Le serveur 60 implemente aussi un client HTTP. A cet effet, il est 
25 raccorde au rSseau 4 par rinterm6diaire d'un serveur proxy HTTP 
supplSmentaire 74 qui peut Stre independant et distinct du serveur proxy 50. 

L'ensemble des serveurs du systeme 2 sont r^alis&s a partir de 
calcuiateurs electroniques conventionnels programmables aptes a executer des 
instructions enregistrees sur un support d'enregistrement d'informations. A cet 
30 effet, les m6moires 30, 40, 41 et 54 comportent des instructions pour 
I'execution du precede SSO des figures 2 a 4 lorsque lesdites instructions sont 
executees par ces calcuiateurs. 
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Le fonctionnement du systeme 2 va maintenant Stre d6crit en regard 
des figures 2 a 4. 

Initialement, lors d'une etape 90, un identificateur du serveur 24 est 
enregistr^ dans ia iiste 76 des serveurs d'authentification connus par 
5 rutilisateur. 

Parallelement, lors d'une 6tape 92, les listes 34 des fournlsseurs de 
services sont mises a jour. 

Ensuite, Tutilisateur du poste 10 se connecte, lors d'une etape 94, au 
reseau 4. Lors de cette etape, Tutilisateur saisit, lors d'une operation 96, un \eu 

10 d'informations permettant de Tidentifier et de Tauthentifier aupres du serveur 52 . 

Une fois que rutilisateur 10 a et§ identifi^ et authentifi^, le serveur 
52, lors d*une operation 98, lui affecte une adresse IP et enregistre la relation 
entre cette adresse r6seau et Tidentificateur de cet utilisateur dans la Iiste 56. 

Ensuite, le serveur 52 informe, lors d'une operation 100, les 

15 diff6rents serveurs d'authentification connus par cet utilisateur que celui-ci a ete 
correctement identifi6 et authenfrfie. Cette identification et authentlfication 
realisee par le serveur 52 est ici associee ^ un niveau d'authentification 6gal & 
"2" de sorte que les serveurs d'authentification memorisent que le niveau 
d'authentification disponible est egal a "2". 

20 Une fois autorise a naviguer sur le reseau 4, rutilisateur se connecte, 

par exemple, lors d'une etape 104, au fournisseur de services 20. Le module 32 
du fournisseur 20 emet alors en reponse, lors d'une operation 106, une requ§te 
d'authentification HTTP incluse dans une r6ponse HTTP a destination du poste 
10. Cette requete est interceptSe par le serveur proxy 50 puis traitee par le 

25 serveur iCAP 60 et enfin transmise jusqu'au serveur d'authentification 24. Cette 
requete d'authentification comporte le niveau d'authentification 36. Le sen/eur 
24 verifie, lors d'une etape 108, que le niveau d'authentification disponible pour 
cet utilisateur est au moins 6gal a "2". Ici, le niveau d'authentification disponible 
Stant 6gal a celui requis par le fournisseur 20, le serveur 24 transmet, lors d'une 

30 etape 110, une r6ponse d'authentification contenant un certificat 
d'authentification au fournisseur 20. Ce certificat informe le fournisseur 20 que 
le niveau d'authentification requis est disponible. 
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Le fournisseur 20 ayant regu le certificat propose alors, lors d'une 
etape 112, d cet utilisateur un service personnalis§ et / ou sScurise sans que 
rutillsateur ait besoin de s'identifier aupr^s du fournisseur 20. Par exempie, le 
fournisseur 20 lui propose i'impression d'une feuilie de paye comportant son 
5 nom. 

Ensuite, toujours lors de la meme connexion, rutillsateur 10 se 
connecte en 114 au fournisseur de services 22. Ce fournisseur 22 execute alors 
roperation 106. 

Toutefois, contrairement au cas precedent. le serveur 
10 d'authentification 24 constate que le niveau d'authentification requis par le 
fournisseur 22 est superieur d celui actuellement disponible pour cet utilisateur. 

Le module 44 de controle d'acces du serveur 24 precede alors d une 
etape 120 d'authentification active lors de laquelie il intenroge rutillsateur, de 
maniere a identifier et a authentifier celui-ci avec une quallte d'authentification 
15 correspondant au niveau d'authentification "4". Par exempie, le module 4A 
demande § rutillsateur de saisir des informations personnelles telles que sa 
date de naissance. 

Si rutillsateur du poste 10 a et6 correctement identifie et authentifi^ 
avec un niveau d'authentification "4", le serveur 24 enregistre le nouveau 
20 niveau d'authentification disponible dans sa memoire 40 et precede a I'etape 
110. 

Ensuite, le foumisseur 22 propose lors d'une etape 122 un service 
personnalise et / ou securise a cet utilisateur. 

Le precede ci-dessus decrit dans le cas particulier des foumisseurs 
25 20, 22, est alors reitSre au fur et & mesure que rutillsateur du poste 10 contacte 
de nouveaux foumisseurs de services. 

Ainsi, grdce d ce procSde, rauthentification de I'utilisateur est 
simpiifiee puisque ceiui-ci ne doit s'idenfifier et s'authenfrfier que lors de l3 
connexion au reseau 4 puis ensuite ^ chaque fois qu'il contacte un foumisseijr 
30 de services exigeant un niveau d'authentification superieur a celui disponible. 
Ce precede pemnet done d'eviter a rutillsateur de saisir, a chaque fois qu'il 
contacte un nouveau fournisseur de services, un jeu d'informations 
d'ident'rfication et d'authentification correspondant a ce foumisseur de services. 
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Les flux d'Informations ^changes entre les §quipements du systeme 
2 iors des etapes 104 d 122 vont maintenant dtre decrits plus en details en 
regard des figures 3 et 4. 

Sur les figures 3 et 4 les blocs rectangulalres repr6sentent des 
5 equipements ou des listes memorisees deja decrites en regard de la figure 1 et 
portent done les memes references. Les fleches entre ces equipements 
representent a la fois le sens de circulation des informations et les operations 
correspondantes . 

Initialement, le navigateur 16 du poste 10 envoie une requete HTTP 

10 vers le module 32 d*un fournisseur de services, par exemple le fournisseur 20. 
Cette requete est achemin6e, Iors d'une operation 130, jusqu'au serveur proxy 
50. L'interfaoe 64 intercepte cette requite et la transmet, Iors d'une op6ration 
132, au serveur 60 et plus precis§ment au sous-module 68. Le sous-module 68 
ajoute un en-t3te d la requSte HTTP indiquant que le systeme 2 supports un 

15 proc6de SSO et retransmet, Iors d'une operation 134 cette requete HTTP ainsi 
modifiee vers le serveur proxy 50. 

Le serveur proxy transmet alors la requete HTTP modifiee jusqu'au 
fournisseur de services Iors d'une operation 136. 

Le module 32 du fournisseur de services detecte la presence de Ten- 

20 tete ajoute par le sous-module 68 et, en reponse, envoie, Iors d'une operation 
138, une requete d'authentification vers le navigateur 16. 

La requete d'authentification est, par exemple, conforme au 
protocole SOAP (Single Object Access Protocol) normalise par Torganisme 
W3C (World Wide Web Consortium). 

25 Cette requete d'authentification comporte notamment un identifiant 

du fournisseur de services, une copie de la liste 34 de sen/eurs 
d'authentification connus, le niveau d'authentification requis par ce fournisseur 
et, par exemple, une instruction connue sous les termes anglais "set cookie" 
destinee d enregistrer un identificateur de la requete d'authentification sur le 

30 poste 10 ou, en variante, directement un identifiant de la requ§te. 

L'interface 64 du serveur proxy 50 intercepte cette requete 
d'authentification et la dirige, Iors d'une operation 140, vers le sous-module 70 
du serveur 60. 
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Le sous-module 70 compare, lors d'une operation 142, la liste 34 
repue d la liste 56 pour s6lectionner le serveur d'authentiflcatlon a contacter, 
par exemple, ici le serveur 24. S'ii n*existe aucun serveur d'authentification 
commun a la liste 34 regue et ^ la liste 56, le sous-module 70 envoie un 
message d'incompatibilit6 au fournisseur de services ayant 6mis la requ§te 
d'authentification. Ce message d'incompatibilite comporte Tidentificateur de la 
requete d'authentification, de maniere a ce que le module 32 puisse relier cette 
reponse a la requete d'authentification correspondante. Uidentificateur de la 
requete d'authentification est. par exemple, celui contenu dans Tinstructlon "set 
cookie", 

Ensuite, le sous-module 70 determine, lors d'une operation 144, 
ridentitd de Tutillsateur du poste 10 en comparant I'adresse reseau du poste 10 
a la liste 76. Cette adresse aura et6 fournie par le serveur proxy 50 au sous- 
module 70 lors de l'op6ration 140 par Tinterm^diaire d'un champ de ren-t§te 
HTTP. 

Une fois rutilisateur identifie, le sous-module 70 procede a une 
operation 148 de transmission de la requSte d'authentification regue associ6e ^ 
ridentificateur de Tutilisateur obtenu lors de Toperation 144, au serveur 
d'authentification selectionne lors de Toperation 142. 

Le serveur 24 compare, lors d'une operation 150, le niveau 
d'authentification disponible pour Tutilisateur a celui requis par le fournisseur de 
services. 

Dans le cas ou le niveau d'authentification requis est superieur a 
celui actuellement enregistr§ par le serveur 24, celui-ci procede comme decrit 
en regard de la figure 4. 

Dans le cas contraire, le serveur 24 envoie lors d'une operation 152. 
une reponse d'authentification au serveur 60. 

Le sous-module 70 regoit la reponse d'authentification et la transmet, 
lors d'une operation 156, vers le fournisseur de services par I'intermediaire du 
serveur proxy 74 et en utilisant le protocole HTTP. Cette r6ponse 
d'authentification comporte si n6cessaire un identificateur de I'utilisateur. 

Le fournisseur de services repond a cette reponse d'authentification 
en transmettant vers le serveur 60, lors d'une operation 158, par exemple, une 
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page d'accueil personnalis^e. Cette rSponse est transmise par rinterm^diaire 
du serveur proxy 74 au serveur 60 en utilisant le protocole HTTP, 

Le sous-module 70 redirige, lors d'une operation 160, cette reponse 
vers le serveur proxy 50 en utilisant le protocole iCAP qui la redirige, a son tour, 
5 lors d'une operation 162, vers le navigateur 16 en utilisant-le protocole HTTP. 

Ainsi, una page d'accueil personnalisee s'affiche sur le navigateur 16 
de Tutilisateur du poste 10 sans meme que cet utilisateur ait eu besoln de 
s'identifier aupres, par exemple, du fournisseur 20. 

La figure 4 represente la circulation des informations entre les 
10 differents 6quipements du systeme 2 dans le cas particulier ou le niveau 
d'authentification requis par le fournisseur de services contacte est superieur a 
celui actuellement memorise dans la mdmoire 40 du serveur 24. Sur cette 
figure, les ^quipements et ies operations d6ja d^crits en regard des figures 1 et 
3 portent les memes references et les nouvelles operations sont representees 
IS en traits gras. 

Lors de Toperation 150, le serveur 24 a etabii que le niveau 
d'authentification requis est superieur §i celui actuellement disponible pour 
Tutilisateur. Par consequent, il precede a une operation 180 lors de laquelle le 
module 44 transmet une requete d'authentification active vers le serveur 60 
20 contenue dans une reponse HTTP et en utilisant le protocole HTTP. La requete 
d'authentification active est destines a activer sur le navigateur 16 un processus 
d'authentification interactif. A cet effet, cette requete comporte ici un formulaire 
a completer par Tutilisateur. 

Le sous-module 70 retransmet lors d'une operation 182, cette 
25 requete d'authentification active vers le serveur proxy 50 en utilisant le 
protocole iCAP, puis le serveur proxy 50 la retransmet, lors d'une operation 
184, vers le navigateur 16 en utilisant le protocole HTTP. Le navigateur 16 
affiche le formulaire qui permet a Tutilisateur de s'identifier et de s'authentifier 
avec un niveau d'authentification superieur, par exemple, §gai a "4" dans le cas 
30 du fournisseur de services 22. Une fois que le formulaire a 6t§ complete, le 
navigateur 16 envoie, lors d'une operation 186, la r6ponse dans une requete 
HTTP. Cette reponse est interceptee par I'interface 64 du serveur 50 et 
transmise, lors d'une operation 188, au sous-module 72 en utilisant le protocole 
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iCAP. Le sous-module 72 retransmet alors, lore d'une operation 190, la reponse 
de rutllisateur en utiiisant le protocole HTTP au serveur 24. Si le formulaire a 
correctement 6te complete par rutllisateur, c'est-a-dire que le jeu d'informations 
d'identificatlon et d'authentification est correcte, le serveur 24 memorise, lors 
5 d*une operation 192, le nouveau niveau d'authentification disponible dans la 
memoire 40 et proodde ensuite a ('operation 152. Les operations suivantes sont 
identiques a ceiles decrites en regard de la figure 2 a Texception du fait que les 
operations 152, 156, 158 et 160 font intervenir le sous-module 72 a la place du 
sous-module 70. 

10 La plupart des serveure proxy existant comportent d^j^ une interface 

iCAP. Ainsi, le syst^me de la figure 2 simplifie la mise en oeuvre du proc^d^ 
SSO puisque la seule modification a apporter au serveur proxy consiste a le 
configurer de maniere § ce que rinterface iCAP intercepte les requetes HTTP 
n^cessaires k la mise en oeuvre de ce proc^dS. 

15 La circulation des flux d'Informations entre les differents Elements du 

syst^me 2 a §t§ decrite dans le cas particulier ou le serveur iCAP 60 
communique directement en utiiisant le protocole HTTP avec le ou les 
fournisseurs de services lors des operations 156 et 158. En variante, le serveur 
iCAP communique avec les foumisseure de services uniquement par 

20 rintermediaire du protocole iCAP. Par exemple, dans cette variante, les 
requetes HTTP emises ^ destination du foumisseur de services lors de 
I'operation 156 sont d'abord transmises par le serveur 60 jusqu'au serveur 
proxy 50 en utiiisant le protocole ICAP puis le sen/eur proxy 50 transmet oes 
requ§tes au foumisseur de services en utiiisant le protocole HTTP. La r§ponse 

25 HTTP emise par le foumisseur de services lors de Toperation 158 suit le chemin 
inveree de la requSte Smise lore de reparation 156. Dans cette variante, le 
serveur 60 ne communique jamais directement avec ies foumisseure de 
services de sorte que ceux-ci ne sont pas au courant de Texistence du serveur 
60. Uutilisation du serveur 60 est alors totalement transparente pour oes 

30 foumisseure de services. Cette variante pr6sente Tavantage que du point de 
vue du foumisseur de services, tous les echanges d'informations se font entre 
lui et Tutilisateur sans avoir connaissance de ['existence du serveur 60. Cette 
variante presente egalement Tavantage que les requetes HTTP emises et 
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regues lors des operations 156 et 158 sont directement dchangSes aveo le 
serveur proxy 50 et non plus par rintermedlaire du sous-module 70 ce qui 
accel^re le traitement de ces operations. 

Les sous-modules 68 a 72 ont ete decrits dans le cas particulier oD 
5 ils sont tous Implementes dans le meme serveur iCAP 60, En variante, ces 
sous-modules sont chacun implementes dans un serveur iCAP independant 
des autres. 

lei, rinterface 64 est configuree pour n'intercepter que les requetes 
HTTP qui doivent etre traitees par ie serveur iCAP. En variante, Tinterface 64 

10 est configuree pour rediriger tous les flux d'informations HTTP vers le serN/^eur 
iCAP et le serveur iCAP implemente un module de flltrage propre a envoyer au 
module de traitement 66 uniquement les requites HTTP qui doivent ©tre 
traitees par ce module. Ainsi, dans cette variante, Tinterception des requites 
HTTP n'est pas realisee par le serveur proxy 50 mais par le serveur iCAP. 

15 Le systSme 2 a ete represents dans le cas particulier oil les serveurs 

d'authentification sont raccordes au fournisseur d'acces intemet par 
rintermedlaire du reseau 4. En variante, au moins Tun de ces serveurs 
d'autfientification est loge chez le fournisseur d'acces internet et raccorde a 
celui-ci par rintermedlaire d'un reseau local independant du reseau 4. Ce mode 

20 de mise en oeuvre avantageux lui permettra de beneficier de toutes les 
identifications / authentifications realisees par le fournisseur d'acces et qui ne 
pourraient etre partagees avec des fournisseurs d'authentification externes pour 
des raisons de securite; 

De meme, en variante, le serveur iCAP est raccorde au serveur 

25 proxy 50 par rintermedlaire d'un reseau grande distance et non plus par 
rinterm§diaire d'une liaison ou d'un reseau local. 

Le syst§me 2 a et& decrit dans le cas particulier oCi la premiere 
authentification de chaque utilisateur est realisee par le fournisseur d'aoc&s 
intemet 12. En variante, cette premiere authentification n'est plus realisee par le 

30 fournisseur d'accSs intemet 12 mais, par exemple, par le premier fournisseur de 
services contacte par Tutilisateur. 

L'identification et Tauthentrfication de Tutilisateur ont ete decrites 
dans le cas particulier ou celle-ci se fait a partir d*un terminal 10 equipe d'un 
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6cran et d'un clavier ce qui permet de saisir un jeu d'informations d'identification 
et d'autlientification. En variante, la premiere identification et authentification de 
Tutilisateur est r6alis§e automatiquement, par exemple, en identrfiant le terminal 
utilise par cet utilisateur. Plus precisement, lorsque ie terminal 10 est rennplace 

5 par un telephone mobile, Tidentification et Tauthentification de I'utiiisateur se font 
automatiquement en proc^dant d Tacquisition du numero de telephone du 
terminal. Dans ce cas, rauthentification est dite transparente. 

Le systems 2 a 6galement ete decrit dans le cas particulier oD las 
serveurs d'authentification memorisent uniquement le niveau d'authentification 

10 disponible pour chaque utilisateur ce qui renforce la securite du systeme 
puisqu'il n'est pas desirable que Tensemble des mots de passe et autres 
informations secretes de Tutilisateur soient enregistres dans un meme lieu. 
Toutefois, en variante, ces serveurs d'authentification memorisent egalement 
en tant qu'informations d'authentification le ou les jeux d'informations 

15 d'identification et d'authentification que chaque utilisateur est susceptible 
d'utiliser pour s'identifier et s'authentifier aupr^s de chaque fournisseur de 
services. Ainsi, dans cette variante, la reponse d'authentification comporte le 
jeu d'informations d'identification et d'authentification a transmettre au 
fournisseur de services pour que celui-ci identifie et authentifie Tutilisateur. Ce 

20 jeu d'informations d'identification et d'authentification est transmis au 
fournisseur de services de fagon similaire a ce qui a ete decrit pour le certificat 
d'authentification. 

Le systeme 2 a ete decrit dans le cas particulier ou la requete 
d'authentification emise par chaque fournisseur de services comporte un niveau 

25 d'authentification. En variante, la requete d'authentification dmise par Tun des 
foumisseurs de services ne comporte pas de niveau d'authentification. Dans 
cette variante, en rSponse §i cette requete d'authentification, le serveur 
d'authentification contacte fournit, en reponse, un certificat d'authentification 
indiquant simplement que I'utiiisateur a §te authentifi§. Ainsi, dans cette 

30 variante, rutilisateur aura acces aux services du fournisseur de services a partir 
du moment oD it a et§ authenfifie au moins une fois et ceci quel que soit le 
niveau de cette authentification. 
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Le systeme 2 a ete decrit dans le cas particulier oCi le rSseau 4 est le 
r^seau internet. Toutefois en variante, ce reseau 4 est un rSseau de 
transmission d'informations quelconque tel qu'un r6seau local, un reseau ^ 
commutation de paquets quelconque ou un reseau a commutation de circuits. 

5 Le syst§me 2 a 6t§ d§crit dans le cas particulier oCi les serveurs 

d'authentification sont aptes a emettre des requetes d'authentification actives 
lorsque ceux-ci ne disposent pas d'une authentification satisfaisante pour 
I'utilisateur. En variante, les serveurs d'authentification ne sont pas aptes a 
§mettre ces requ§tes d'authentification actives. D6s lors, dans cette variante, 

10 lorsqu'un serveur d'authentification est contacte alors qu'il ne possede, par 
exemple, aucune infomiation d'authentification sur Tutilisateur, il est apte ^ 
emettre un message d'enreur d la place d'une requ§te d'authentification active. 

FInalement. le systdme 2 a §t§ dScrIt dans le cas particulier oCi le 
protocole de transfert de flux HTTP est le protocole iCAP. En variante, le 

15 protocole iCAP peut etre remplacS par tout autre protocole de transfert de flux 
HTTP tel que par exemple le protocole OOP (OPES Call Out Protocol) avec 
OPES (Open Pluggable Edge Services). 

Le systeme 2 a ete deflnl en faisant reference aux recommandations 
6tablies par Liberty Alliance. Toutefois, I'invention revendiqu^e n'est pas limitee 

20 aux syst6mes et aux procedes conformes aux recommandations de Liberty 
Alliance et s'applique ^ tout systdme ou proc6d6 pr6sentant des fonctionnalites 
similaires ^ celles decrites ici. 
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REVENDICATIONS 



1. Systeme d'acces a un reseau (4) a commutation de paquets 
5 adapte pour la mise en ceuvre d'un precede a signature simplifiee, ce systeme 
comportant : 

- un serveur proxy (50) par lequel passent tous les flux 
d'informations echang§s entre un utilisateur et ledit r§seau, 

- plusieurs fournisseurs (20, 22) de services raccordes audit 
10 reseau (4), chaque fournisseur de services §tant apte a Smettre une requete 

d*authentification vers rutilisateur qui le contacte pour identifier et/ou authentifier 
cet utilisateur avant de iui fournir des services personnalisSs et/ou securises, la 
reponse ^ fournir par un mSme utilisateur ^ cette requete d'authentification 
pouvant etre differente en fonction du fournisseur de services contacte, 

15 - au moins un serveur d'authentification (24, 26) propre a 

memoriser au moins une information d'authentification pour chaque utilisateur 
et a transmettre en reponse a une requete d'authentification une reponse 
d'authentification contenant une information d'authentification fonction a la fois 
du fournisseur de services ayant ^mis la requete d'authentification, et de 

20 ridentitd de I'utiiisateur ayant contacts ce fournisseur de services, et 

- un module (66) d signature simplifiee apte d traiter 
automatiquement en lieu et place de I'utiiisateur les requetes d'authentification 
§mises par les fournisseurs de services contactes, ce module Stant apte pour 
chaque utilisateur : 

25 - a diriger les requetes d'authentification vers le serveur 

d'authentification (24, 26) approprie, et 

- a retransmettre au fournisseur de services la reponse 
d'authentification correspondan^ transmise par le serveur d'authentification 
approprie. 

30 caracterise en ce qu'il comporte un serveur supplementaire (60) 

independent du serveur proxy (50), le module a signature simplifiee (66) 6tant 
implements dans ce serveur supplementaire (60), et en ce que le serveur proxy 
(50) est equips d'une interface (64) permettant de le raccorder au serveur 
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supplementaire (60) et de transmettre au moins les requStes d*authentification 
^mises par les fournisseurs de services contactSs audit serveur supplementaire 
(60) pour traitement de ces requetes par le module §i signature simplifiee (66). 

2. Syst^me selon la revendication 1, caracterise en ce que le module 
5 a signature simplifiee (66) comporte un sous-module (70) propre a identifier 

rutilisateur a partir de son adresse reseau et a sjouter un identificateur de 
rutilisateur aux requetes d'authentification dirig6es vers les serveurs 
d'authentification. 

3. Systeme selon Tune quelconque des revendications precedentes, 
10 caracterise en ce que ladite au moins une information d'authentification 

m^morisee pour chaque utiiisateur comprend une information sur un niveau 
d'authentification disponible pour cet utiiisateur, en ce que chaque requete 
d'autiientification emise par un foumisseur de services (20, 22) spScifie des 
caracteristiques sur le niveau d'authentification requis par ce fournisseur de 

15 services pour pouvoir acceder aux services qu'll propose, en ce que le ou 
chaque serveur d'authentification (24, 26) est apte a comparer les 
caracteristiques sur le niveau d'authentification requis specifie par la requSte 
d*authentification a Tinformation sur le niveau d^authentification disponible, de 
maniere a determiner si le niveau d'authentification requis correspond au 

20 niveau d'authentification disponible pour cet utiiisateur, et en ce que le ou 
chaque serveur d'authentification (24, 26) est apte a emettre vers rutilisateur 
une requete d'authentification active propre S activer un processus interacts 
d'identification et/ou d'authentification de rutilisateur si le niveau 
d'authentification requis ne correspond pas au niveau d'authentification 

25 disponible. 

4. Systeme selon la revendication 3, caracterise en ce que le serveur 
supplementaire (60) comporte un sous-module (72> propre d dinger la r^ponse 
de rutilisateur aux requetes d'authentification active vers le serveur 
d'authentification qui Fa 6mise. 

30 5. Systeme selon la revendication 3 ou 4 caracterise en ce que le 

sen/eur supplementaire comporte un sous module (70) propre a diriger la 
requete d'authentification active vers I'utilisateur. 
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6. Systeme selon Tune quelconque des revendications prec^dentes, 
caracteris^ en ce que le module ^ signature simpiifiee (66) comporte un sous- 
module (68) capable d'ajouter aux requetes transmises par Tutilisateur vers un 
fournlsseur de services un signal d'identification de service ^ signature 

5 simpiifiee en reponse auquel le fournisseur de services emet la requete 
d'authentification . 

7. Systeme selon Tune quelconque des revendications precedentes, 
caracterise en ce que le serveur suppiementaire (60) et le serveur proxy (50) 
sont aptes a communiquer i'un avec I 'autre en mettant en oeuvre un protocole 

10 de transferl de flux HTTP (Hyper Text Transfer Protocol). 

8. Systeme selon la revendication 7, caract6ris6 en ce que le 
protocole de transfer! de flux HTTP est le protocole iCAP (Internet Content 
Adaptation Protocol) ou le protocole OCP (OPES Call Out Protocol). 

9. Systeme selon la revendication 7 ou 8, caract6ris§ en ce que le 
15 serveur suppiementaire (60) est uniquement apte k communiquer avec les 

fournisseurs de services par i'intermSdiaire du protocole de transfert de flux 
HTTP mis en oeuvre entre lui et le sen^eur proxy (50). 

10. Systeme selon Tune quelconque des revendications 1 a 8, 
caracterise en ce que le serveur suppiementaire (60) implemente egalement un 

20 serveur et/ou un client HTTP (Hyper Text Transfer Protocol) pour communiquer 
directement avec le ou chaque fournisseur de services et/ou le ou chaque 
serveur d'authentification uniquement a Taide du protocole HTTP. 

11. Systeme selon i'une quelconque des revendications 
precedentes, caracterise en ce qu'il comporte un fournisseur d'acces (12) audit 

25 reseau (4) auquel doit se connecter rutiiisateur pour pouvoir acceder audit 
rSseau, ce fournisseur d'acces Stant §quip§ du serveur proxy (50). 

12. Systeme selon Tune quelconque des revendications 
precedentes, caracterise en ce que ledit reseau est la toile d'araign^e mondiale. 

13. Serveur suppiementaire apte d §tre mis en oeuvre dans un 
30 systeme conforme a Tune quelconque des revendications pr6c6dentes, 

caracterise en ce quil comporte le module a signature simpiifiee (66) apte a 
traiter automatiquement en lieu et place de Tutilisateur les requetes 
d'authentification emises par le ou chaque foumisseur de services contacts, et 
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est apte a communlquer avec un serveur proxy (50) pour recevoir au moins les 
requ§tes d'authentification emises par les fournisseurs de services. 
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